COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	The MAIL program.				Oct 21, 1974
C00028 00003	The REMIND command.
C00040 00004	MAIL to ARPA network hosts
C00052 00005	Interfacing to MAIL from other programs
C00060 ENDMK
C⊗;
The MAIL program.				Oct 21, 1974

This document describes the use of the MAIL and SEND monitor
commands, which are used to send messages to users.  The SEND
command sends the message to the user's console, if he is logged in,
and optionally may also (or instead, if he isn't logged in) send it
to him as MAIL, so it will be seen on login.  The second section
describes the REMIND command, for automatic delayed messages, and
the LATER command, for automatic delayed program execution.

The basic format of the MAIL command is

	.MAIL <switches> <destination list> <message>

and that of the SEND command is

	.SEND <switches> <destination list> <message>

Another command, for complaining about system bugs, has the format

	.GRIPE <message>

This is a version of MAIL which is directed to a special system area.

A final special-purpose command is PLAN, which creates a file intended
to describe your projected whereabouts, travel plans, etc. to other
users who may look for you while you are away.  The format is

	.PLAN <message>

Unlike the other MAIL commands, PLAN creates a file containing only the
message in the command rather than adding the message to any previously
created messages.  Also, if you use a null message, your plan file is
deleted.  The plan files are read by the FINGER program.

Switches allowed with any of MAIL, SEND, and REMIND are /D and /U. The
/D switch causes a list of the destinations specified by the command
to be added to the message as its last line, preceded by "CC: ".  If
a distribution list file is used, both the file spec and the
contents are included.  Note: all specified destinations are listed,
even if invalid.

The /U switch is used if for some reason you need to send a message
to a user who is not known to the system (has no UFD).  It allows
this but gives a warning message and asks you for each unknown
addressee whether you really mean it.  These switches may also be
used with SEND and REMIND, in addition to the ones listed below.

The /A (append) switch may be used only with the MAIL command, and
means that the text you give should be appended to the most recent
message from you (i.e., from a user with your login programmer name)
to each recipient.  If there is no such message, the switch is
ignored.  It is also ignored for recipients at other ARPA net sites.

The /T (Tenex, or Topic) switch, used with the MAIL command, allows
the inclusion of a "subject" line in the text of the message.
This switch is meant to be used with ARPA network mail, and is
described more fully in the ARPA section of this document, below.

There are three mutually exclusive switches which may optionally be
used with the SEND command.  All have to do with the option of
mailing messages. Normally, SEND will just send messages to consoles
of logged-in users (at all consoles where logged in), but if a
destination of the form PRG (see the next paragraph) is not logged
in anywhere, the user will be given the option of mailing the
message to that prg instead.  The switches /Y for Yes or /N for No
will assume that response whenever the situation arises.  The switch
/M for Mail will always mail to all destinations on the list as well
as sending to their consoles even if they are logged in.

Another switch used with SEND or MAIL is /W, for "where", which lists
on the user's console the ppn, job number, job name, queue, and
console number of all (logged in) recipients of the message.

The destination list for MAIL can be just * , which will send the
message to the file NOTICE.TXT[2,2] so all users will see it on
login. Otherwise, it is one or more project and/or programmer names
separated by commas.  The elements of the list should be in the form
PRG or [PRJ,*] or [PRJ,PRG] .  Any PRJ or PRG can be a dot (.) to
mean the same as the user's prj or prg name (real ppn, not alias).
List elements may also take the form @<file specification> (default
device DSK, default extension DIS as in DIStribution list); the
specified file will be read and will replace the @ field in the
command.  If such a file contains an @ field, the newly specified
file will be read and the remainder of the old file, if any, will be
ignored.  The DIS file may have a TV/E directory and/or SOS line
numbers, which will be ignored.  (Note: if the file specification
does not give an explicit extension, the given file name with no
extension will be tried before the default extension given above.)
The DIS file may have any number of lines; destinations are
separated by any combination of crlfs, spaces, and zero or one
comma.  Lines in the DIS file may contain comments started by
semicolons, which will be ignored; note that this is not true of the
command line typed at the console!  In the @ file specification, the
notation [PRJ] may be used to mean [PRJ,.].  The notation ↓chars↓
may be used to include non-alphamerics in a file name.  To make it
easier to refer to mail files as messages (see below), the filename
scanner will also accept "filenames" of the form ∂ or ∂PRG or
∂PRJ,PRG or ∂PRJ, or ∂PRJ,*.  The first case uses your own logged in
programmer name, as does the ∂PRJ, form.  These imply device DSK,
and default extension MSG and ppn [2,2], although extension or ppn
can be specified explicitly.

MAIL also allows the use of destinations at a foreign ARPA network
site.  This facility is described at the end of this document, after
the REMIND system documentation.

The MAIL command will also send messages to an arbitrary file of
your choice; this feature may be used, for example, to maintain
a diary file.  Only one such destination may be used in a single
MAIL command, although other, standard destinations may be used
in the same command.  If the desired output file already exists,
you may specify whether you want the message added at the beginning,
as for standard mail files, or at the end.  The destination syntax is
:<file> for the beginning, or &<file> for the end.  The file must
be on device DSK.  Any filename may be used, as in the @ syntax; the
default extension is .MSG and the default PPN is your current alias.
All the usual switches may be used, except that /A does not affect
a &<file> destination.

If there is a file called OUTGO.MSG on your (login, not alias) directory,
MAIL will save your message at the front of that file as well as mailing
it to the specified destinations.  The distribution list will be
included in this file whether or not you use the /D switch.

If you do not know the programmer name for a user, you can use his
human being type name instead (first or last name).  The name will
be found in the file of authorized users, if it is present there,
and you will be told the programmer name for that user to encourage
you to use it in the future (it's faster).  If there is more than
one user with the name you give, it tells you all the relevant
programmer names and invites you to try again.

For the SEND command, there are several special forms of destination: a
job number, the device name of a terminal followed optionally by a colon,
* (sends to all logged-in users), and ARPA* (sends to all users
logged in via the ARPA network).  Any of these special forms, if used,
must be the only destination specified.

The message part of the command may be a one-line message, which
will be sent as is; or an @file specification (default extension
TXT); or null, in which case the program will request a multi-line
message from the user.  Any TV/E directory, SOS line numbers, and
form feeds in a message file will be ignored.  If you start typing
a short message on the command line, and decide you need more than
one line after all, you can end the command line with <lf> instead
of <cr> and you will be allowed to continue the message.

When entering a multi-line message from a Stanford display terminal,
you can edit the message with E automatically, and then continue
sending the message, by typing <control><meta>E (anywhere in a
message text line).  The message will be saved temporarily in a file
named MAIL.TXT on your (alias) PPN, and E will be started editing
that file.  When the message is complete and ready to send, type the
E command <control>X RUN which will restart MAIL, sending the message
and deleting the MAIL.TXT file.

Messages can only be sent to real consoles, or to pseudo-ttys
which are connected to the IMP (ARPA users).  This excludes
detached jobs and non-ARPA PTYs.  SEND * sends only to those
consoles at which someone is logged in.

When a message is sent to a display console (III or DataDisc),
the MAIL program tries to determine whether the recipient is
running some program, such as E, which changes the normal page
printer positioning thereby making it possible that the message
will be lost.  If it finds anything unusual about the page
printer, it warns the sender of this in a message including
the ppn, job name, etc. of the recipient as in the /W output.
The sender may choose at this point to REEnter and change the
SEND to MAIL.  (The REEnter facility is explained below.)
SEND * does not type out these warnings.

Mail can only be sent to defined users, i.e., there must be a
UFD matching the destination prj and/or prg names (unless the
/U switch is used, as explained above, to permit it).  The mail
is put in the front of the file <ppn>.MSG[2,2].  If the mail
is sent to all users via MAIL *, the program also scans the old
NOTICE.TXT[2,2] file as it copies it, and deletes any messages
more than two weeks old.  Also, TV directories and SOS line
numbers are deleted from the old messages in this case.

Another special feature of MAIL * is that an expiration date may
be specified for the message.  The format is
	.MAIL *→ <date> <message>
where <date> can be in any of the date formats allowed for the
REMIND command (see next page) except that wildcard dates are not
allowed, and only the date (no time) may be specified.  The date
given is the one on which the message will be deleted, i.e., it
will be seen last on the previous date.  This expiration feature
is implemented by including the expiration date in the message
header, and entering (as with the LATER command described on the
next page) a request to run the program EXPIRE.DMP[RMD,SYS] on
the specified date.  This latter program deletes any expired
messages.  This implementation is described because the CANCEL
command (see next page) will list the request for the EXPIRE
program, so you should expect that if you use this feature.  If
no expiration date is specified, the message is still eligible
for deletion after two weeks as described above.

The check for a file directory for the specified user(s) is made
before the program asks for the message if the multi-line option
is used.  If there are no valid destinations, the program exits
without doing anything else.  If any destinations are valid,
however, the program asks if you wish to continue, and if so
it continues as if only the valid destinations
were specified.  (Exception: the list provided by /D includes
all specified destinations, valid or invalid.)  The special case
of a command like "SEND PRJ,PRG" where what is meant is
"SEND [PRJ,PRG]" will be caught if PRJ is not the name of a
programmer, and the (probable) desired effect is simulated
with a warning message given.  Note: in the case of SEND,
you are given a warning message if a destination user is valid but
not logged in.  This warning, unlike the message for an invalid
destination, does not require you to reconfirm your desire to
continue.  After you finish typing in the message, you are again
notified of not-logged-in destinations as described earlier.

There is actually a way not-logged-in users can get messages sent by
SEND: it is possible to declare a particular console to be your
"home" console for SEND purposes.  If you have a file called
OPTION.TXT[1,prg] which includes a line of the form SEND:number then
if someone sends you a message with SEND and you are not logged in,
a message will be typed on the tty specified by the above number
indicating that the message is coming, and it will be mailed as if
the sender had said SEND/Y.  You can read the message by saying RCV
prg. You need not be logged in to do this, but if you are it
destroys your core image.  Oh, yeah, if the message is sent to
[prj,prg] rather than prg, it looks for OPTION.TXT in [prj,prg]
rather than [1,prg].


When a message is MAILed by the MAIL command (not SEND/M, etc.)
to a user who is logged in, a one-line notice is sent to his
console indicating that mail has arrived.  This also applies to
mail-only reminders (see REMIND/M, next section).

A sample command is
MAIL BH,@FOONLY,[S,*] TEXT OF MESSAGE
which will send the message "TEXT OF MESSAGE" to ↓    BH↓.MSG[2,2],
↓  S↓.MSG[2,2], and whatever users are listed in FOONLY.DIS in
the user's disk area.

Spaces may be used in all reasonable places in the command.  For
the benefit of any weird people who want to start messages with
a comma, there is another syntax in which the destination list
is enclosed in parentheses.  In this case spaces may separate
destinations instead of commas if you want.  This syntax is also
handy for SENDing to a numeric programmer name (otherwise it
would be considered a job number) and similarly useless things.

There is an error recovery feature for people who type in long
messages, only to discover that because of a typing error they are
trying to send it to a non-existent destination or something; to
wit: If, at the end of a multi-line message, you type
<ctrl><meta><altmode> instead of <ctrl><meta><linefeed>, the message
will not be transmitted. Instead, the original command will be
loaded into your line editor, and you can correct and re-enter it,
but if it does not include a message, the old message will be used
instead of asking for a new one. Also, the same effect can be gotten
by giving a monitor REENTER command after the program exits or you
<call> out of it.  From a non-display teletype, of course, the line
editor feature is not available, but you can still REENTER and
retype the command line. Note: this reenter facility only works
after the message has been completely entered; do not <call> in the
middle of typing the message and reenter, use <ctrl><meta><altmode>
instead.

The mail program can be invoked by other programs in three ways.
First, there is the usual RPG system: if SYS:MAIL.DMP is started at
one location after its usual start address, it will try to read a
TMPCOR file MAI (or a disk file QQMAIL.RPG if no TMPCOR file is found)
which should contain the command.  This file may
not contain line numbers or a directory, just the command. The
command is scanned up to a linefeed or zero byte, except that only
the first 32. words of the file are examined, so long messages must
be entered with the @ feature.  If no RPG file is found, MAIL will
request a command from the teletype.  Another procedure is also
allowed, to make it easier to send messages without having to write
a file: if MAIL is started two locations after its start address, it
does a WRCV and will accept a command in its mailbox.  Programs
written to use this feature should wait between the SWAP and the
SEND UUOs in order to make sure the program was really loaded,
otherwise the mail will be lost.  Some other considerations:
obviously, if the MAIL job does not have a teletype, the long
message input mode cannot be used; if the command has neither the
message text nor a message file specification, nothing is done.
Also, in this case, SEND with no switches is equivalent to SEND/Y.
If the command file in RPG startup does not have a message or @
specification in the command line, the file DSK:MAIL.TXT will be
read as the message text and will be deleted after reading.

The third and best way to interface between MAIL and other
programs is described on page 5 below.
The REMIND command.
--- ------ --------

The REMIND command is used to tell the MAIL program to send and mail
your message at a specified later date and time, possibly repeatedly.
The basic syntax is

	.REMIND <switches> <destination list> <datime> <count> <message>

The allowable switches are /S for send only or /M for mail only.  If
neither is used, the message is both sent and mailed.  /D and /U may
also be used, as in MAIL or SEND.

The destination list and message fields function like those of the
MAIL command, as described in the previous section.  Reminder
recipients must be users known to the system, i.e., they must have a
UFD (unless you use the /U switch as explained on the previous
page).  The destination field may be omitted, in which case your own
programmer name will be used as if the destination field were the
character "."; NOTE, however, that some forms of datime (those which
start with a letter) could be confused with destinations, and if you
want to use such a form there must be an explicit destination.

The datime field may specify a date, a time, or both.  The formats
allowed for dates are illustrated here:

	4/28/75		28-APR-75	APR 28, 75
	4/28/1975	28-APR-1975	APR 28, 1975
	4/28		28-APR		APR 28
	4/28/*		28-APR-*	APR 28, *
	*/28		28-*		+3
	WED		WED*		W		W*

The forms without a year imply this year unless the date is today or
earlier, in which case next year is used.  Letters may be upper or
lower case; all after the first three are ignored.  The days of the
week have, for convenience, the single-letter names familiar to
Farmers' Almanac readers and former MIT students: M,T,W,R,F,S,D.
Asterisk as a month or year is wildcard; note that forms like */28
expire at the end of the current year.  WED* and W* mean every Wednesday.
The +3 form is the number of days later than today, i.e., three days
from now.  Spaces may generally be used or omitted as desired except
within a word or number, except for the APR 28 forms.  Certain mixed
notations such as "4/28, 1973" may work, or they may not.  If only a
time field is used without a date, today is assumed unless the time
is already past, in which case tomorrow is used.  The weekday forms
always imply a day between one and seven days from now as their first
or only instance, never today.  Here are the formats for times:

	1423		223pm		223p
	14:23		2:23pm		2:23p
	0223		223am		223a		223
	02:23		2:23am		2:23a		2:23
	2		2am		2pm		2a
	+2:23		+2:		+:23		2p

A date without a time means midnight.  The relative forms may only
be used without a date.  Letters may be upper or lower case.  There
may be spaces on either side of a colon, but NOT between the time
and the "am" or "pm"!  To use both a date and a time, they must be
enclosed in parentheses and separated by spaces: "(WED 3am)".  A time
without a date may be followed by asterisk (*), in which case the
reminder will be sent every day at the specified time.

The optional count field is used to specify the number of instances
of a repeated request.  The format is #<number>.  If none is used,
#50 is assumed (the number is decimal).  The form #∞ may be used for
requests which are to live forever, but please don't leave these
around after you go away....

When a reminder which is sent more than once is sent for the last time
because its count expires, a warning to that effect is appended to the
text of the message.  Also, the message is mailed even if REMIND/S was
used, to ensure that the expiration notice is seen even if the recipient
is not logged in then.  This does not apply to a message which is not
rescheduled because of the specified datime, such as a date of */10
which expires at the end of the year.

Here are sample commands:
	REMIND . (WED* 2:45P) #30 Go to 3:00 class!!
	Remind me, sir, to monitor your computer usage.
	REMIND * APR 15,* LAST DAY TO FILE INCOME TAX RETURNS

The messages will be both sent and mailed at the target time,
unless /S or /M is used to specify send-only or mail-only.  The
message header will say "(reminder)" to distinguish it from an
ordinary message.  All the features of MAIL work here, like @ fields
for destinations or messages, REENTER, etc.  There are the usual
syntactic ambiguities which are not expected to affect anyone in
practice: if the first nonblank after the command name is a digit,
it is taken as part of the datime field in REMIND, as opposed to
a programmer name in MAIL or a job number in SEND.

Because the data structure in which the reminder system stores messages
is rather sensitive to ios␈␈uε#πS∃ε;⊃β&K7∃βNs≠?KnS'?raβ←#.qβS#(h+Og∨#↔5β≡{7↔Mπ+Aβπ7#↔Iβ
β∂Kπ≡Aβ←'&Aβ←#∂!βO↔.kMβ3N[∃βπrβW;K.O?;∞∪3∀4VK∪↔¬ε{→βSF)β∪π&)β?Iπ#'7∃bβ;=β⊗+7';&+KMβ>K31β⊗)βπ∂≡+CS↔"β?Iβ&+3'[/∪↔⊂4W+;S'bβS#∃π≠gOS.iβ#π~β↔↔rβWAβ6{Iβπ"β3↔π∨!β≠'6)β7'w+S↔Mr↓↓"#␈β↔≠Wfceβπph+↔K⊗{Iβ'rβS#∃ε#πS∃ε{IβSNk∃β←Nc1β#∂3∃β.+9β∂␈∪K↔∂&+⊃βJβS#↔rq$4(hRS#∃∧bεR⊗∩β∂?7n;⊃βO→βWO.!βS=ε≠πWO*β∪↔3∂K↔⊃β/C↔∂SN{9β?2βπ9β∂∪'S⊗Kd4WβK?∨⊗59↓¬##∃β6{K7π"β'MhhP4(%tbεR⊗∩↓s≠'f+OC↔≠q↓s∂␈∪∃y↓f#πS'n)y↓s≡{W;Qph(4+Nqβ←#N≠!β∪∂#'7∃ε;⊃β≡{W;QεK∃β∂→β'9π##∃α∀*6&:"β∂?7n;⊃9ααS#∃ε3'3↔∨β↔4V#↔S↔⊗k';↔~βS#∃πβK?∨⊗5βSzβ∃β↔+9mβ&C∃β∪.3πW3"β∪↔[N≠∃β'~α∩N-αCS#∃ε{;3dhS?S#/⊃β∪↔6K∂∃β∞c3?←.!β'M¬~fM%bβπ;⊃π##∃β&+≠πWg!β↔c&+;O'}qβ'M∧"6A9αα;?S+P4+'2β;=βπβ9β'~βOC↔≡K≠'↔"aβS#*βCC9π+O↔⊃εKMβg␈+Iβ∪O≠-βCεq↓#πfKπM%εQβSF(4+SNk∃βSF)β∂?nkπ;⊃εKMβ↔w#↔K↔"	↓αSF)β∪↔fg↔⊃εS?	βO→β∨'6+9βg␈+Iβ3};∨↔⊃nK84+πβ9βπ~β'SMεc?∨∨.!7'9πβC9β⊗+∨πK&c↔OMε{→βSF)βCCrβ?→β&C∃β∪.kAβ≠Nc∃9↓∧KP4+O→βKWrβ←'SBα*2>:β?≠→bβ%;∃raβ'QεKMβ/Nc3↔⊃εK→βπwIβ↔K⊗{Iβ∂}s∪'SN{9βπ⊗KO↔Mph*S#*β?CSN{;π1ε≠?K∃εK∨Wn+;Q1εK→βW≡+⊃1βO→β↔;≡c?O↔"β'9β∞s∨3∃ε∪Kπ∂↑+SM8hR'Qβneβ'v≠3W∪*βπ9βNs'S'∞aβ∂?⊗)βπ3f{∂πSN{9βπv!??Iε	βOS∂∪S';:βπ∪∪⊗+OL4V{≠≠O/!1β'rβS#∃ε3?K5α⊃qN-bYEy	r↓αS#*βOW∂∪∨W7.sSMβneβ*β'9β.KS#↔⊂h-o9
order, and must be separated by a comma if both are used.  The core
allocation argument is in decimal units of 1024 words, and the
starting address offset is in octal words.  If no job slots are
available at the time the job is to be run, it is not done; therefore,
if you are depending on the result you should schedule the job for
non-prime time. (If there is no job slot for the REMIND phantom
itself, it will try to schedule your job as soon after the given time
as it is itself run, but it will only try once.)

The monitor command CANCEL will run a program which will list and
selectively delete reminder requests from or to you, or all requests
if you are logged in as [RMD,SYS].  This program can also be used to
list requests without asking whether you want to delete them: after
the first request is listed, type the letter L in answer to the
deletion question and any remaining requests will be listed without
interruption.  LATER requests are also listed and deleted by CANCEL.
Since the program run for you by the CANCEL command has to share the
use of the reminder storage file with the system reminder phantom job,
there will sometimes be delays in the listing of reminders.  An
appropriate message is typed in this case.

Complaints regarding these programs should be addressed to:
	Wastebasket
	Room 50-030
	Copernicus, The Moon  99973
MAIL to ARPA network hosts

The MAIL command allows mail to be sent to users at other ARPA
network sites.

(This service is not available to network guests, sorry.)

Since the "@" character was already used in MAIL to specify a file
to be read for command arguments, the character "%" is used to
signify ARPA site names, e.g., BH%SU-AI not BH@SU-AI.  Site names
can follow a user name, as above, or can be used alone (followed by
a space) as a "sticky" site:
	MAIL %MIT-AI RG,TK,MINSKY,BH%SAIL,PAPERT
will send the message to RG, TK, MINSKY, and PAPERT at MIT-AI, and
to BH at SAIL.  (Of course, if SAIL is used as the site name the
mail is not actually sent through the network!)

User names for foreign hosts can be of (essentially) arbitrary length.
If the name is a string of letters and digits starting with a letter,
it can simply be typed as is: TEITELMAN % MAXC for example.  (The case
of letters is preserved, in case it matters to the foreign host.)  If
the user name contains characters other than letters and digits, or
starts with a digit, enclose it in quotes (") with two quotes used to
represent a single quote if necessary.  The host name cannot contain
any special characters except hyphen.  Partial site names are recognized
as in our TELNET and FTP programs.  Also, a decimal number may be used
instead of a host name if necessary.

If the destination list in a MAIL command includes PPNs at SAIL (which
must be enclosed in square brackets), SAIL is assumed as the destination
host and should not be specified explicitly, e.g.,
	MAIL %AI [1,BH],TK
mails to TK at MIT-AI and [1,BH] at SAIL.  To mail to a PPN somewhere
else, you must say, e.g.:
	MAIL "[N900AR00]"%CMU

The outcome of an attempt to send network mail is reported to you, in
a format somewhat like SNDMSG in TENEX.  The possible outcomes are
	USER at SITE -- ok
	USER at SITE -- refused
	USER at SITE -- queued
	USER at SITE -- failed
The first case means that the mail was successfully sent.  The second
means that the network connection was made successfully but the MAIL
command was rejected, possibly because there is no such user at that
host.

Network mail will be queued if it cannot be sent when
you make the request (remote host down, etc.)  The mail is queued via
the REMIND phantom.  The status report from the MAIL command is "queued".
The mail will be retried at three-hour intervals for three days.  If
it is sent successfully, or if the three days run out and the request
is deleted, you will receive a status report from the REMIND phantom,
in the form of a reminder from yourself saying
	ARPA network mail to USER at SITE -- ok
if successful, or
	ARPA network mail to USER at SITE -- expired
if not.  The date and time in the header of this status report will be
the time when the message is actually sent successfully (or deleted).
The date and time in the header of the message sent to the remote site
is the time when you originally tried to send the message.

The CANCEL command lists ARPA mail which you have queued and allows
you to abort the request.  The listing by CANCEL contains the text
of your message and the name of the addressee, but lists his site by
number rather than by name.  It also specifies the number of attempts
remaining before the request will be deleted.

It is also possible to get a status report saying
	ARPA network mail to USER at SITE -- refused
if the connection to the remote host is made successfully but the
remote host refuses the mail.  This status report will also include
any error message we may get back from the remote host.

It is possible to get a "failed" status report from a network
MAIL command if the program is unable to enter the request in the
REMIND queue, for instance because there are no job slots available
for the phantom.  In this case you must try again later yourself.
(You can save the text of a long message you have typed in by giving
the monitor REENTER command after MAIL exits and redirecting the
mail to yourself.)

If a message which was typed in (i.e., not from a @FILE construction)
returns either a queued or a failed response, the text of the message
is saved in a file FAILED.TXT in your (alias) directory.  This should
not be necessary for queued mail, which will eventually be sent
automatically if possible, but is necessary for failed and reassuring
for queued.  The file contains the message as typed, i.e., no header
of either internal or external format, and no space added in front of
each line.  If the file cannot be entered (e.g., you are aliased to a
write protected directory), nothing special is done, but if the file
is written successfully you are so informed.

Usually if the mail is refused, and possibly otherwise, the remote host
will send us error messages intended to be helpful to you.  If any such
messages are received which are not part of the normal MAIL sequence,
they are typed out along with the status report.  Thus you can hopefully
figure out why the mail was refused.

Mail to foreign hosts is prefixed with a TENEX-ish header including your
real name, if known to the system, and your net address (PRG @ SU-AI).
Thus recipients should be able to figure out how to reply.

Distribution list files as in MAIL @FILE can, naturally, include
network destinations.  The /D switch, which includes the list of
addressees in the message, includes network addressees, as typed
(e.g., with abbreviated site names if that's what you typed).  The
message header as sent to each net addressee has his site name
in full, with his user ID as you typed it.

For those misguided souls who want their network mail to be compatible
with the TENEX READMAIL program, it is possible to include a
subject line in the message header by using the /T switch in the
MAIL command (for Tenex, or Topic if you like).  This switch takes
the first line of text in the message as the subject line, and also
forces multi-line input (as if the command line ended with lf instead
of cr).  Thus the input command
	MAIL/T TESLER%MAXC Horrible PUB problem<cr>
	I tried to run PUB and this is what happened:...
	...
	<control><meta><lf>
will produce a message like this:
	Date: 29-Sep-74  1:55 PM
	From: Brian Harvey (BH @ SU-AI)
	Subject: Horrible PUB problem
	To:   TESLER at PARC-MAXC
	- - - -
	I tried to run PUB and this is what happened:...
	...
	-------
If the text input is from a file, the first line of the file will be
used as the subject.  If local (SAIL) destinations are included in
the command, the message as received locally will be:
	∂29-Sep-74  1358	1,BH
	 Subject: Horrible PUB problem
	 I tried to run PUB and this is what happened:...
	 ...
If a network mail attempt fails and a FAILED.TXT file is written,
it will contain:
	Horrible PUB problem
	I tried to run PUB and this is what happened:...
	...
A later command of the form MAIL/T TESLER%MAXC @FAILED
will therefore do the right thing.

If a network mail attempt fails and is queued, the message as listed
by the CANCEL command will not contain the subject line, but it's
really there, fear not.
Interfacing to MAIL from other programs

The best way to run MAIL from another program is to start SYS:MAIL.DMP
at one LESS than its normal start address, by SWAP UUO, after leaving
your ACs set up with information for MAIL as described below.  The
message text must first be written in a DSK or TMPCOR file; disk files
may contain a TV/E directory and/or SOS line numbers.  It is possible
to tell MAIL to restart your program by SWAP, returning the same values
in the ACs.  Here is what to put in the ACs:

0-5 SWAP UUO arguments for return after MAIL if desired:
	 0  device
	 1  filename
	 2  ext,,mode bits (see UUO Manual)
	 3  core,,start addr increment
	 4  file PPN
	 5  login PPN if starting new job
6-16 MAIL arguments for destination, file with message, and flags:
	 6  destination PPN or special (see below)
	 7  ext of nonstandard destination file
	10  PPN of nonstandard destination file
	11  text file name
	12  text file ext
	13  unused
	14  text file PPN
	15  date and time if REMIND, see below
	16  flags, see below
17 is used as the SWAP AC and is not preserved in return after MAIL.

The flags in 16 are as follows:
	400000,,0	/N switch for SEND
	200000,,0	* is destination
	  4000,,0	text file is TMPCOR rather than DSK
	  2000,,0	do SWAP UUO with argument in ACs 0-5 instead of exiting
	  1000,,0	delete message input file (ACs 11-14) after reading it
	   400,,0	ARPA* destination for SEND (200000,,0 must also be on)
	   200,,0	job number destination for SEND
	   100,,0	device name (TTYn) destination for SEND
	    40,,0	&FILE destination for MAIL (20,,0 must also be on)
	    20,,0	:FILE destination for MAIL
	    10,,0	/T switch for MAIL
	     4,,0	REMIND
	     2,,0	MAIL, or /M switch for SEND
	     1,,0	SEND

	     1000	/S switch for REMIND, or /W switch for SEND or MAIL
	      400	/M switch for REMIND
	       10	/Y switch for SEND
	        1	/A switch for MAIL

If the message text is in a TMPCOR file, the file name is taken from the
left half of 11, and the alias PPN is the MAIL job's alias PPN.  Note that
to use TMPCOR the program which writes the file must be the same job number
as the MAIL ob, i.e., you must start MAIL in your own job, not start
another job.  Also please note that the 1000,,0 bit applies to TMPCOR
files as well as DSK, and is strongly recommended for TMPCOR.

The destination in 6 is normally a sixbit PPN or (right adjusted)
programmer name.  If flag 20,,0 is on, it is a file name for MAIL
to a nonstandard file, whose extension and PPN are in 7 and 10.
The 2,,0 flag must be on, and the 1,,0 flag must be off, for this
form of destination.  If flag 200,,0 is on, the destination is a
(binary) job number; if flag 100,,0 is on, the destination is a
sixbit device name, which must be that of a TTY.  For both of these
cases, the 1,,0 flag must be on.  If the 200000,,0 flag is on, the
destination in 6 is ignored.

The text input file, and the nonstandard MAIL output file if used,
must be on device DSK.  However, no default extensions are used;
if AC 12 or 7 is zero a null extension is implied.  A zero PPN uses
the user's alias PPN as usual.

If the 4,,0 flag is on, to specify a REMIND operation, the 2,,0 and
1,,0 flags must be off.  Also, AC 15 must contain the date and/or time
argument, in the following format:

	BYTE (4)MONTH(5)DAY(6)YEAR(3)DAY-OF-WEEK(6)HRS,MINS,FLAGS

A non-zero day-of-week field means repeat the reminder every week;
Wednesday is 1 and Tuesday is 7.  If the day-of-week field is
not used, the month, day, and year fields specify the date (except
for exceptions, see below).  The month and/or year fields may be
zero for wildcard; otherwise 1 means January, etc., for month and
1 means 1965 etc. for year.  The day of the month field is one
less than the date, e.g., 0 for the first of the month.

Special cases: for a particular date, put the date in DAYCNT format
(see UUO manual) in the left half, and set bit 35 on (0,,1).
For today, leave the left half zero; for tomorrow, leave the left
half zero but set bit 34 (0,,2) on.  To repeat the reminder every
day, leave the left half zero and set bit 33 (4,,0) on.

For the time, HRS is the number of hours past midnight and MINS the
number of minutes past the hour.

For MAIL * you may specify an expiration date (but not time).  If you
are doing MAIL * (or SEND/M *) and do not want to use this feature,
AC 15 must be zero.

If you want a date or time relative to the current one, you must
do the calculations in your own program.

Not all features of MAIL are available with this technique.  The
main deficiency is multiple destinations, of course.  Others are
the /D switch, ARPA network mail, PLAN, LATER, and expiration
counts.  Also, if the swap return feature is not used, the user
cannot use the REENTER command to repeat the operation you do.